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REMARKS 

This amendment is being filed in response to the Office Action having a mailing 
date of August 6, 2008. Various claims are amended as shown. New claims 33-34 are added. 
No new matter has been added. Claim 32 is canceled herein without prejudice. With this 
amendment, claims 1-31 and 33-34 are pending in the application. 

I. Rejection under 35 U.S.C. § 1 12 

The present Office Action rejected claim 4 under 35 U.S.C. § 112, second 
paragraph, for allegedly being indefinite. 

While it is respectfiiUy submitted that claim 4 in its previously presented form 
meets definiteness requirements, claim 4 is nevertheless amended herein to facilitate prosecution 
and to provide further definiteness. In view of this amendment to claim 4, it is kindly requested 
that the indefiniteness rejection be withdrawn. 

II. Discussion of the claims and cited references 

The present Office Action rejected claims 1-6, 9-15, 17-22, 24-29 and 32 under 
35 U.S.C. § 103(a) as being unpatentable over Mankude (U.S. Patent No. 6,795,866) in view of 
Egevang (U.S. Patent Application Publication No. 2003/0081605). Claims 7, 16, and 30 were 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Mankude in view of Egevang and 
in fiirther view of Iny (U.S. Patent Application Publication No. 2002/0061030). Claims 8, 23, 
and 31 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Mankude in view of 
Egevang, and further in view of Malagrino (U.S. Patent No. 6,714,985). 

For the reasons set forth below, these rejections are respectfully traversed. It is 
therefore kindly requested that the Examiner reconsider and withdraw the rejections. 

A. Independent claim 1 

Independent claim 1 is amended herein to include some of the subject matter fi-om 
previously presented dependent claim 32, with claim 32 now canceled herein without prejudice. 
More specifically, claim 1 as amended herein recites, inter alia, "processing the head fragment to 
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determine a destination address for said head fragment and forwarding said head fragment to said 
determined destination address " and " applying said destination address ... to at least one 
non-head fragment of said packet that was stored prior to receiving said head fragment and to at 
least one non-head fragment of said packet that is received after said forwarding said head 
fragment ." It is respectfully submitted that these limitations are not met by the cited references, 
whether singly or in combination. 

For example, page 4 (section 5) of the present Office Action has admitted that 
Mankude has not very clearly mentioned '"applying (e.g., tagging) the determined destination 
address to any corresponding stored plurality non-head fragment after the session is generated' 
and 'an exit point coupled to the network device to update non-head fragments'." 

To supply the missing teachings of Mankude, the present Office Action relies 
upon Egevang. However, it is respectfully submitted that Egevang does not cure the deficiencies 
of Mankude. 

More particularly, the present Office Action cites Egevang as teaching the 
following (emphasis ours): 



"Egevang discloses a router means comprising a packet fragmentation 
manager (PFM) comprising a collection module receives packet fragments 
([0045] lines 1-5) and then following receiving a first packet fragment 
(header), a translation module will translate destination address to 
subsequent packet fragments based on the first packet fragment 
destination address and network address translation (NAT) process 
([0047]). The translation and modifying steps may read on as applying the 
determined destination address to the non-head packet fragments . 
Thereafter, a communication module (exit point) applies (modifies) the 
destination address based on the NAT process which is determined by the 
first packet fragment destination address ([0048] lines 1-3 & 7-1 1)." 
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What the present OfRce Action's above-quoted interpretation of Egevang fails to 
recognize, however, is that Egevang waits to collect/receive all of his packet fragments before he 
begins the NAT process to determine the destination address for the fragments and before he 
begins forwarding the fragments to the destination address. Specifically, Egevang teaches the 
following in his paragraph [0046] reproduced below (emphasis ours): 

"[0046] Verification module 404 may use the offset values and the packet 
length received from collection module 402 to verify whether all the 
packet fragments for a particular packet have been received . Each offset 
value may represent a position from the starting position to the ending 
position of the original packet. The ending position may be represented 
by, for example, the packet length. Verification module 404 may, for 
example, maintain a verification table indexed by position segments, and 
fill in the table as the packet fragments are collected bv collection module 
402. For example, the position segments may be represented in bytes 
divided by eight (8). Once all the table entries are filled, verification 
module 404 may send a message to translation module 406 to begin the 
NAT process . A timer may be used to determine whether empty table 
entries exist prior to timer expiration. If such a condition occurs, 
verification module 404 may send a message to communication module 
408 to release all queued packet fragments for use by system or network. 
For example, the queued packet fragments may be processed using the 
normal assembly/disassembly packet fragmentation process as defined by 
the IP Specification." 

Thus from the above-quoted passage of Egevang, it is abundantly clear that he 
provides the verification module 404 to verify "whether all the packet fragments for a particular 
packet have been received" and then begins the NAT process after all of the packet fragments 
have been received. Thus, Egevang does not determine/apply the destination address (using the 
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NAT process) until after all fragments are received, and so thereft)re explicitly/implicitly also 
does not or cannot perform any fragment forwarding to the destination address until after all 
fragments are received (since the destination address to forward the packets cannot be known 
until after all fragments are received). In view of these teachings of Egevang that involve 
delaying any forwarding until all fragments are received, it is therefore respectfully submitted 
that Egevang does not meet at least the limitations of claim 1 that require "applying said 
destination address for said head fragment, which was determined by said processing of said 
head fragment ... to at least one non-head fragment of said packet that is received after said 
forwarding said head fragment ." 

Accordingly, claim 1 is allowable. 

B. Independent claims 9. 13. 17. 20. and 28 

Independent claims 9, 13, 17, 20, and 28 are amended herein to recite subject 
matter generally similar to claim 1 above, using varying language. Thus for reasons analogous 
to those explained above, claims 9, 13, 17, 20, and 28 are also allowable. 

C. Other claim amendments 

Various other amendments are made to the claims as shown to provide 
appropriate antecedent basis, to provide consistent recitations between and within related claims, 
to more precisely recite the subject matter contained therein, to make grammatical/typographical 
updates, and/or to otherwise place such claims in better form. 

Claims 21 and 29 are amended to recite, inter alia, that the fragments received by 
the switch are fragmented from the packet by a router. It is respectfully submitted that these 
limitations pertaining to a switch and router and fragmentation are not met by the cited 
references. For example, page 7 (section 5) of the present Office Action has interpreted 
Egevang's router 110 having the packet fragmentation manager (PFM) as being "a switch 
network device." However, it is respectfiiUy submitted that a "switch" is not the same as a 
"router," and that a person skilled in the art would recognize that these two devices are not the 
same/synonymous devices. With the amendments to claims 21 and 29, it is clarified that the 
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router and the switch are not one and the same device, since the router performs the 
fragmentation to obtain the fragments received by the switch. Claims 21 and 29 are thus further 

allowable. 

D. New claims 33-34 

New independent claim 33 recites subject matter generally along the lines of those 
found in previously presented claims 28, 30, and 31, which were rejected on the basis of 
Mankude, Egevang, Iny, and Malagrino. Claim 33 recites an apparatus that includes a switch 
adapted to, inter alia, receive a head fragment of a packet. It is respectfully submitted that claim 
33 is allowable over the cited references, whether singly or in combination. 

For example, page 7 (section 5) of the present Office Action has interpreted 
Egevang's router 110 having the packet fragmentation manager (PFM) as being "a switch 
network device." However, it is respectfully submitted that a "switch" is not the same as a 
"router," and that a person skilled in the art would recognize that these two devices are not the 
same/synonymous devices. 

Claim 34 depends upon claim 33 and recites, inter alia, that the switch is adapted 
to apply the determined destination address to the non-head fragment that is received after the 
head fragment is forwarded. As previously explained above, the cited references do not provide 
this feature, since for example, Egevang needs to receive all of his fragments before he performs 
forwarding. 

In view of the above, it is respectfully submitted that claims 33 and 34 are 

allowable. 

111. Conclusion 

If there are any informalities or questions that can be addressed via telephone, the 
Examiner is encouraged to contact the attorney of record (Dennis M. de Guzman) at (206) 
622-4900. 

The Director is authorized to charge any additional fees due by way of this 
Amendment, or credit any overpayment, to our Deposit Account No. 19-1090. 



15 



Application No. 10/630,494 

Reply to Office Action dated August 6, 2008 



All of the claims remaining in the application are believed to be allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited. 



Respectfiilly submitted, 

SEED Intellectual Property Law Group pllc 

/Dennis M. de Guzman/ 



Dennis M. dc Guzman 
Registration No. 41,702 

DMD:wt 



701 Fifth Avenue, Suite 5400 
Seattle, Washington 98104 
Phone: (206)622-4900 
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